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FOREWORD 


In response to job order 88-079, this functional design 
specification defines the total systems approach to meeting 
the requirements stated in the Detailed Requirements 
Document for Stowage List and Hardware Tracking System, LEC- 
5362, JSC-09405 dated February 1975. The Stowage List and 
Hardware Tracking system is identified at the system and 
subsystem level with each subsystem, defined as a function of 
the total system. 
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1 • 0 GENERAL 
1.1 IDENTIFICATION 

This Functional Design Specification (FDS) document has 
been prepared for the Institutional Data System Division 
(IDSD) of the Johnson Space Center (JSC) by the Shuttle 
Information Management Department of Lockheed Electronics 
Company, Inc. (LEC) . The Stowage List and Hardware Tracking 
System (SLAHTS) is being developed as an element of the 
Shuttle Program Information Hanagement System (SPINS) , for 
four direct users: 

. s 

• Program Operations office - Integration Division 

• Safety, Reliability and Quality Assurance - Quality 
Assurance Division 

• Engineering and Development Directorate - Spacecraft 
Design Division 

• Flight Operations Directorate > Crew Training and 
Procedures Division 


1.2 PURPOSE 

The SLAHTS will provide the user organizations with an 
integrated management and documentation tool to support the 
following functions: 

Orbiter hardware stowage tracking 
orbiter stowage design 

definition and dissemination of procedural • 

nomenclature 

Inventory control of orbiter flight hardware 
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• Inventory control of all JSC bonded storage hardware 

• Inventory control of orbiter training hardware 

1.3 BACK6BOUMO 


All four direct SLAHTS users will be actively engaged 
in Shuttle Orbiter hardware stowage and JSC hardware 
tracking. In order to provide rapid, and accurate 
cOnnunication it is reguired that a connon integrated data 
base be available to all users in an on-line node. 
Coordination and conaunication anong these four users is 
essential. 


Additional background infornation nay be obtained fron 
the SLAHTS detailed reguirenents docunent (reference 3) . 

The renainder of the docunent defines those functions of the 
tour users which can best be provided through an infornation 
processing systes. 

1.4 DESIGN CONSTRAINTS 


The Stowage List and Hardware Tracking System will 
utilize the following JSC SPINS conputer system. SLAHTS 
will require shared use of the following hardware. 






CYBER 70 series conputer 
CDC 844 disk nass storage 
One 7-track nagnetic tape drive 
Hagnetic tapes 

Terninal Control Systen (TCS) Conputer 
Nine JSC HOPS (Hazeltine 4000G) terninals 
(Hazeltine 2000 terninals nay be substituted for 


some of these terminals) 

• Card Reader 

• High Speed Printer 


The SLAHTS is required to reside with and operate asiing 
the following software: 


a KRONOS 

• TCS 

• Common Software 

• System 2000 


CYBER operating system 

i \ 

Terminal Control System 

SPINS applications shared routines 

Data Base management system 


The system requires both on-line interaction and batch 
processing. The SLAHTS application code will be written 
primarily in FORTRAN Extended language. 


1.5 SYSTEM INTERFACES 
1.5.1 Other Systems 


The Stowage List and Hardware Tracking System data base 
will initially be loaded from the JSC Bonded Storage System 
currently operating on a JSC Univac 1100 series computer. 
This interface is described in detail in section 3.1, Data 
Base Establishment. 

During the operational stage of the SLAHTS, an 
interface with the SPINS Mass Properties Program via 
magnetic tape is required. A tape will be output by the 
SLAHTS. It will contain stowage information relevant to 
weight distributions and will be input to the Mass 
Properties program on the Univac 1100 series computer. 

System interface is shown in figure 1-1. 
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DATA BASE LOAD INTERFACE 



FIGURE l-l SLANTS INTERFACE CHART 


1-4 








1.5.2 Users 


The SLAHTS will interface with its users via on-line 
and batch processing. The on-line operations of the StAHTS 
will allow interactive input and interactive query of data 
in a tine sharing environment. Batch processing will 
provide data base size maintenance and data dissemination to 
other organizations via batch reporting. 

1.6 DEFINITION OP TERMS 

t 1 

Common Software - Terra applied to the application 
software subroutines being developed by LEG to be 
utilized by SPIMS applications. It consists of a 
library of subroutines which can be called by the 
application software to perforn specific functions. 

KRONOS - A time-sharing system oriented toward 

interactive terminal operations. Also supports 
local batch processing concurrent with terminal 
users. 

TELEX - A KRONOS subsystem providing support for 
interactive processing from remote terminals. 

ICE ^ Interface Control Executive - a communications 
processor for the Cyber 70/TCS interfiles. Supports 
all the TCS protocol required to accomplish the two- 
way communications between terminals and tho Cyber 
70. 


TCS - Terminal Control System comprised of a Oaivac 494 
Computer and all of the communications and 
associated equipment required to accomplish terminal 
input and output. 

System 2000 (S2K) ** Data Base Hanaqement System 
developec’ by HRI Systems Corporation. 

HOPS Terminals (Hazeltine 4000G) *■ Video display 

terminals with two video intensities for 
foreground/background form processing. The terminal 
screen size is 53 lines with 74 characters per line. 

Hazeltine 2000 - Video display terminal with two video 
intensities for foreground/background form 
processing. The terminal screen size is 27 lines 
with 74 characters per line. 

Subtask - A collection of logical or arithmetic 
operations required to perform a specifically 
defined activity. The subtask* s content is 
determined by such factors as: 

in Core storage available 

(2) An "optimum” size 

(3) Complexity of the activity 

Task - One or more subtasks logically chained to 
perform a predetermined action. 

Transaction - The process by which an on-line system 
directs a programmed function to a predetermined 
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conclusion. A transaction is initiated by an 
individual user. A transaction includes the input 
nessages, the computer processing and the sending o£ 
any output messages associated with the function. 
Additional terminal and mass storage I/O, under 
computer direction, may be required to fulfill the 
initial users request. The transaction is 
terminated by the final output messages associated 
with the initial users request or by user 
interruptions. 

Common Data Pool - The communications blcjck; (core 

storage) and the Mass Storage files used to provide 
temporary storage of data and parameters. 

Task chain - One or more tasks which are scheduled 
serially to process a transaction. 

Subtask Chain - One or more subtasks vhich are 
scheduled serially to process a task. 
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2 . 0 ^ST&M_D£SIG N 

2.1 SYSTEM AaCHITECTORB 

Data to the SLAHTS are derived from the operations of 
the four SLAHTS users and will be input by on-line 
interaction urith the user. These data are edited, validated 
and stored in the integrated SLAHTS data base. Output from 
the system will be by on-line queries and batch reporting. 

2.1. 1 System Flow 

Input to the system will be by interactive use of five 
update displays: 

• Basic Data - Display 01 

• Serial Data - Display 02 

• Flight Configuration Definition - Display 03 

• Flight Location/Serial Configuration Data - Display 04 

• Flight SLCN History - Display 05 

In addition to the five displays listed above, which 
will also be used for on-line reporting, the following 
displays are exclusively used for on-line reporting. 

• Function/System Classification Query - Display 06 

• Location Inventory Query - Display 07 

• Flight Configuration Change Query - Display 08 

• Serial History Query - Display 09 

The SLAHTS on-line and batch subsystem flow is 
illustrated of figure 2-1. 


2-1 




REMOTe 
TERHINAL 



SLANTS 

ONLINE 

SUBSYSTEM 


ima 

DISPLAYS 01t02»03t04«05 
OUTPUT 

DISPLAYS 01t02t03t04«05« 
06f07f08«Q9 . 


BATCH REPORT 
REQUESTS 


EDIT TABLE 
UPDATES 




SLANTS 

BATCN 

SUBSYSTEM 


BATCH REPORTS 
01 THROUGH 24 


FIGURE 2-1 SLANTS SYSTEM FLOW 
2-2 


/ 





FlC.U'^t 2-1 SLAHTi FLOW 


r 

5 J 


SIGS-C.N 


bASLC 

■ . ; - 

serial 



If 


IF 


CCl 

jcci 1 

001 i 

001 

!coT! 

|C02 

002! 

i 

002 

A 

Ld 

c j 

0 

[jj 

i ^ 


c 


ffRA-SSACTlOH; 

INTfUPRFTFR 


X 




{ 

1 


TrrtTT" 


srmu 


CONFi&J- 


histcky 


RATION 


OLERY 


CHANGE 




QUERY 




IF 


IF 



I 


f LIGHT 

configurationI 

DEFINITION 


IF 


T 


flight 


flight 


LOCATION/ 


SLCN 


SERIAL 


HISTORY 


CONFIGURATION 




IF 


IF 



003 

1p03 

003 

003 

A 


c 

0 


00^1 DOA; 

. I ! c i 


FUNCTIONS 

SYSTEM 

CLASSIFI- 

CATION 


IF 


LncATidiw 

inventory 

wUERY 


IF 


005 


005 

Ibos |oQ6| |007j 

Doaj 

A 


R 

Li. LiJ Ld 

R ! 


D09| 

1 

R 


IS I GN-r • 


TYPICAL transactions 



retrieve 

chance 

Q£L£I£ 

SlgNrflSa 

US!t=Of:E 

IF 

IF 

IF 

IF 

IF 

RT 

RT 

RT 

PT 

RT 

RT 

IF 

SC 

AR 

AR 

SC 

AR 

UT 

OY 

PG 

PG 

AC 

SC 


AA 

WT 

RT 

UT 

WT 


WT ' - 


SC 






CV 






PG 





AC 

MT 


WHERE 

i<r * HEAD TEpyiNAL ! 

IF a imtializf Fcny ! 

sc * SECLPITY ; 

cv ^ DATA VALIXATICN ! 

WT X mkite ierkinal 

PC a PAGING 

AR a DATA BASE ACCESSCR=ADJ 

AA a data ease ACCESSIAOC) < 

AC a data rase ACCeSSlCKANGEI 

AC a RATA EASE ACCESSIDELETEI < 

tCl a DISPLAY 01 . 

GC2 a c: SPLAY 02 { 

DCS = El SPLAY 03 
CCA = DISPLAY CA 
DCS a DISPLAY 05 
CC6 ■ CISPLAY 06 
CC7 a DISPLAY 07 
0C3 a DISPLAY Ca 
DC9 a DISPLAY 09 









MGURt: ?-l SLAMTS SYSTEM FLOW 
2 - 2,2 



S2ICBW REFORTS 

LCGISTICS MANAGEMENT (ITEM LEVELI 
LCGISTICS management f SERIAL NUMBER LEVEL! 
master BCNC RCOH STORAGE LIST 
NCMEN'CLATURE DEFINITION 
RESPONSIBLE CRGAMZATIQN LIST 
SHELF LIFE EXPIRATION LIST 
ANNUAL INVENTORY LIST 
ECUIPMENT CLASS 3 

training hardware recuirements and status 

TRAINING HARDWARE MASTER INVENTORY 
SUSPENSE FILE 
DATA ELEMENT EDIT TABLE 
NCTE LIST 


P.LI^£.gR TRRN 

STOWAGE LIST 
PREPACK PROCEDURE* 

STOWAGE LOCKER 
POST FLIGHT DISPOSITION 
ALPHABETICAL PROCEDURAL NOMENCLATURE 
FLIGHT ECUIPMENT SERIAL NUMBER 
FLIGHT LOCATION/EliUIPMENT 
INFLIGHT TRANSFER LIST 
FLIGHT DATA REPRODUCTION 
FUNCTIQNAL/SYSTEH CLASSIFICATION 
STOWAGE LIST CHANGE NOTICE 
FLIGHT DELETION 
MASS PROPERTIES INTERFACE TAPE 
EDIT TABLE MAINTENANCE 



2. 1.2 Subsystem Description 

The SLAHTS will operate as two independent subsystems; 
the on-line processing sdsbsystemr and the batch processing 
subsystem. Figure 2-1 illustrates the basic high level 
system flow. 


2. 1.2.1 On-j in e Pro c essi ng Subsy stem. The SLAHTS 
terminal user will be in communication with the SLAHTS on- 
line processor. The on-line subsystem will process all 
terminal input/output, data validatioUf security 
requirements and data base updates. Nine on-line displays 
will be available for SLAHTS users. These display 
transactions, along with other support transactions, are 
described in more detail in section 2.3.2 of this document. 

The on-line processing subsystem will operate in a 
transaction processing environment. Section 2. 1.3.4 On-line 
processing describes the design approach of this subsystem. 

Terminal communicatons are via common software. 

Extended Core Storage, TELEX/ICE, and TCS as shown in figure 
2-2 and described in the ’’Systems Requirements Document of 
Shuttle Program Information Management System”, reference 5. 

2. 1.2.2 Batch Proc essing Sub system . The batch 
processing subsystem of the SLAHTS will provide 24 batch 
reports for the user. In conjunction with two of these 
reports, additional batch data base maintenance processing 
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FIGWE 2-2 SLAHTS ON-LINE SUBSYSTEM 
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will be acconplished . Edit table .updates and interface with 
the spins Hass Properties prograa will also be provided via 
the batch processing subsystem. Section 2.3.3 of this 
document provides a more detailed description of these 
modules. 

2.1.3 Design Approach 

The SLAHTS is designed to operate on the JSC CDC CYBER 
70 series computer. It will provide an integrated computer 
system consisting of on-line interaction, batch reporting 
and batch processing. 

Terminal Input/output will be via one of two video 
display terminals, the Hazeltine 2000 or the Uazeltine 4000G 
(HOPS) terminals. These two terminals provide form mode 
interface between user and system. Section 2. 1.3.1 of this 
document describes the user/terminal/computer interface 
designed in SLAHTS and contains an explanation of form mode 
processing. 

The System 2000 data base management software to be 
used by the SLAHTS was selected by the PICRS study (see 
reference 7) . System 2000 is a software product of the MHI 
corporation and provides a sophisticated data management 
tool for information storage and retrieval. The use of the 
System 2000 will be transparent to the SLAHTS user in that 
there will be no direct user interface to System 2000. 
Section 2. 1.3.3 of this document describes the features of 
System 2000 which will be utilized by the SLAHTS. 
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The SLAHTS design approach is specified in the 
following four sections of this docunent. 

2. 1.3.1 Tera in al In ter face. The SLAHTS has been 
designed to provide the user and terninal operator an easy 
to use nethod of on-line coonunicatioa. The nethod of 
terninal/user Interface will be a forn node operation 
utilizing the capabilities of the Hazeltine 2000 and 
Hazeltine 4000G terninals. 

The SLAHTS forms will consist of headings, titles, and 
other labeling and tutorial data, and of parameter areas 
into which the user enters those data needed to describe his 
guery or data base update. The format of the nine displays 
used in the SLAHTS are described in the Detailed Reguirenent 
Document (DUD) (reference 3) . Figure 2-3 is a duplicate of 
the Basic Data Display, as defined in the DUD and is 
included here as an example of a SLAHTS form. 

The foreground/background Intensity capabilities of the 
two terminals will enhance the usability of forn mode 
input/output. The tutorial data will be displayed in 
background intensity. Parameters which are input by the 
user, or those which nay be updated by the user will be 
displayed in foreground intensity. The remainder of the 
parameter data from a query action will be displayed in 
background intensity. This use of foreground/background 
will prevent inadvertent attempts to update or add data 
elements to which the user does not have update authority. 
This tutorial process, supplemented with the data base 
security described in section 2.3. 1.3 provides an easy to 
use, effective security system. 
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FIGURE 2-3 BASIC DATA DISPLAY FORM 
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Under the forearoundi/baclcground conf iguration, the TAD 
key on the terminal keyboard can be used to positon the 
cursor directly to the beginning of the next foreground 
parameter field on the form, thus eliminating the necessity 
of manually moving the cursor character by character to the 
desired parameter field. 

lihen a query results in multiple pages of output or 
when using a Hazeltine 2000, paging will be provided by 
SLAHTS. The user will be allowed to page forward, backward, 
and skip to the desired page. 

2. 1.3.2 Common Softwa re. The SPIMS Common Software 
was conceived as a method for minimizing development and 
maintenance cost of the SPIMS applications while reducing 
the time-frame of their development. The SLAHTS will make 
use of the SPIBS common software routines as described in 
the Common Software Detailed Requirement Document and 
Functional Design Specification (references 4 and 8) . 

Since common software will be provided as a series of 
subroutines callable from SLAHTS tasks, the user will 
communicate with a completely integrated package. The use 
of common software will therefore be transparent to the 
user. 

Common software will provide the following routines: 

• Terminal Interface routines 

• Limited Data Element Editing routines 

• Utility routines 
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The Terminal Interface routines will provide the data 
paths and interfaces to communicate with the user terminals. 
These data paths are illustrated in figure 2-2 and are fully 
de£ln€?d in the Common Software DHO (reference 4) • 

The Data Element Validation routines provided by common 
software will be supplemented by additional SLAUTS routines 
and used for data element validation. 

The utility routines provided by common software will 
include String Packages, and File Input/Output routines. 

The SLAHTS, in order to conserve cote, will utilize the 
common software File Input/output routines instead of 
standard FORTBAN I/O to access SLAHTS mass storage files. 
Section 3.4 of the Common Software DRD (reference 4) gives 
additional descriptions of the Utility routines to be used. 

2. 1.3. 3 System ^QOQ. System 2000 is the general 
purpose data base management system to be used by SLAHTS. 
Following is a list of several System 2000 features SLAHTS 
will util ize. 

SLAHTS will use the Basic Natural Language feature to 
define the data base. Natural Language will also be 
employed by the data base administrator to provide data base 
backup and security. 
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POBTBAN language subroutines will utilize the 
Procedural Language (PLI) feature to manipulate data in the 
Systeii 2000 data base. This feature vill be utilized in 
both the on**Iine processing subsystea and the Batch 
processing subsystem. 

The Report writer feature will be used by the SLAHTS in 
generating thirteen of the SLAHTS batch reports (see section 
2.3.2). 

System 2000 multi-user, multi-thread features will 
allow concurrent access to the data base. This feature 
allows all SLAHTS users update access to the data base at 
the same time. SLAHTS will protect against concurrent 
nbdif ications to the sane logical entry. The single copy 
version of System 2000 will be used by the Batch processing 
subsystem. 


Reference 9 provides a detailed description of System 


2000 . 


2. 1.3.4 On-Line Processing. User initiated queries 
an!d updates will be processed using transaction processing 
techniques. The SLAHTS on-line transactions are listed 
below and are explained in further detail in section 2.3.2 
of this document. 


Sign On Transaction 
Basic Data Transactions 
Serial Data Transactions 

Flight Configuration Definition Transactions 
Flight LoGation/Serial Configuration Transactions 



• Flight SLCN History Transaction 

• Function/System Classification Transaction 

• Location Inventory Transaction 

• Flight Configuration Transaction 

• Serial History Transaction 

• Sign Off Transaction 

K transaction will be processed by the serial execution 
of a chain of tasks. A task is a logical subset of. a 
transaction and frequently will be used to process aore than 
one type of transaction. The task types which will be 
provided are: 

Transaction Interpreter 

Initialize FORM 

Security 

Data Editing and Validation 

Read Terminal 

Vrite Terminal 

Paging 

Data Base Access 

These tasks are described in further detail in 
paragraph 2.3.1 of this document. Figure 2.4 illustrates an 
example transaction. 

2.1.3.S Batch Proc essing. The SLAHTS Batch Processing 
Subsystem is designed to fulfill the batch processing and 
report requirements specified in the SLAHTS DBD (reference 
3) • 
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FIGURE 2-4 BASIC DATA ACO^ ON-LINE TRANSACTION 
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Prom one to twenty-seven batch runs may be executed 
£tom a single computer job by supplying the corresponding 
input cards. Stand-alone programs will be provided for 
history processing and data base loading. The input card 
formats are described in Appendix A of this document. 

The batch processing subsystem is designed to fully 
utilize the report generation capabilities of System 2000, 
supplemented with FOBTBAN coding for those reports which 
cannot be generated via standard System 2000 output. Figure 
2-5 illustrates the SLAHTS batch subsystem. 

Two methods of report generation will be utilized by 
the SLAHTS. The two types of processing are listed below 
and each report module is listed as a member of one of these 
types. 

I PLI/FQBTBAN j^pplicat ion Code 
Stowage List Report 
Prepack Procedure Report 
Stowage Locker Report 
post Flight Disposition Report 
Alphabetical Procedural Nomenclature Report 
Flight Equipment Serial Number Report 
Flight Locat ion/Eguipment Report 
inflight Transfer List Report 
Flight Data Reproduction 
Functional/System .Classif ication 
Stowage List Change Notice Report 
Flight Deletion 
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FIGURE 2-5 SLAHTS BATCH SUBSYSTEM 







II Systei 20 00 Report Writer 

• Logistics Hanagement Beport (Iten Levels 

• Logistics Hanagement Report (Serial Number 
Level) 

• Master Bond Room Storage List 

• Nomenclature Definition Report 

• Responsible Organization List 

• Shelf Life Expiration List 

• Annual Inventory List 

• Equipment Class 3 Report 

• Training Hardware Requirements and Status 

• Training Hardware Master Inventory Report 

• Suspense File Report 

• Data Element Edit, Ta.ble Report 

• Note. List 

Type I (PLI/PTN) reports are generally of a complex 
nature. They require FORTRAN application code processing 
and decision making during report generation. Normally, 
complex data retrievals are required to fulfill the report 
requirements. 

Type II (S2KRN) reports are generated via the System 
2000 Report Writer. , 

The method of determining which type of report 
generation is to be used is a function of several variables. 
First, since the cost of development of a S2KRH report is 

i 

minor compared to that of a PLI/FTN report, each report was 
considered as a S2KRW candidate. Those reports in which 
disjoint data sets are required (a limitation of S2KRN) were 
catagorized as PLI/FTN after a determination of the cost of 
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redundant data elements. Some reports which have coaplex 
report fotaats could only be generated using PLI/FTN. 

In addition to batch reports, the Batch processing 
subsystem will provide the following: 

• Data Base Maintenance of the History Files 

• QhD data base loading 
Mass Properties Interface Tape 

• Edit Table Maintenance 

• Flight Configuration Data Reproduction 

The batch modules and programs are defined in section 
2«3.3 of this document. 


2.2 FILE DEFINITION 

The following files will be utilized or generated by 
the SLIHT system: 

• System 2000 Data Base - a set of six associated 
direct access files, with an associated update 
file. Appendix B contains the data base format 
definitions and a data base map. 

• Local files - created during execution for 
temporary storage of data. These files are 
released upon completion of the run. 

• Mass Properties Input Tape - created by the Batch 
Subsystem. The tape format is specified in fhe 



Detailed Reguireaents Docuaent for SLAHTS 
(reference 3) • 

2.3 SOBSYSTEM SPECIFICATIONS 
2.3.1 On-Line Processing Subsystem - Tasks 

2.3. 1,1 Tra nsac ti on Interpreter . The SLAHTS 
transaction interpreter will control the logic flow of the. 
On-Line Subsystem through a transaction processing sequence. 
This will be accomplished by first determining, from user 
inputs, the transaction to be processed. This determination 
will result in a list of tasks being linked which when 
executed in sequence will process the transaction request 
and provide any resulting transaction output. Execution of 
this list will be initiated by the interpreter using the 
transaction task loader. Each task in the list will be 
loaded and executed in the order it appears in the list. 

The following table of tasks will be used to create the task 
list required to process user transactions: 

1. Initialize form 

2. Security 

3. Data editing and validation 

4. Read terminal 

5. Write terminal 

6. Paging 

7. Data base access 

Output from the interpreter will consist of the 
transaction processing task list and any other required task 
inputs. 
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2.3. 1.2 Initialize JForat , This task establishes the 
currently active blank fora to be displayed. A fora for 
each of the transactions will be available. 

The fora vill be«defined as a string of characters 
containing the coded coaaands to the terminals necessary to 
construct a FORH on the screen. Sach terainal type vill 
require a unique FOBH descriptor. Coaaon Software routines 
will be used in this task. 
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2. 3. 1.3 Security . The SLftHTS is designed to provide 
several different users with an unrestricted read capability 
and a diverse update capability. To handle these functions, 
a number of security tasks will be created, each of which is 
designed to validate a certain update request. Data base 
security will be provided by several subtasks, each of which 
will be created corresponding to the update transaction. 

The Sign-on security task will be required to insure that 
the user attempting sign on is using one of the following 
access codes: 

Type User 

1 Universal Read Ability to read all data in the data 

base but unable to perform updates 
of any kind. 

2 ID Password used by the Integration 

Division. 

3 QAD Password used by Safety Reliability 

and equality Assurance. 

4 FOD Password used by the Flight 

Operations Directorate. 

5 EGD Password used by the Engineering and 

Development Division. 

6 Batch Report Password used to request batch 

reports. 
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7 Oanipotent Pass¥ord which probably only the 

Operations Chief will have. This 
password will allow the user to 
alter the coded value of any 
password, it will also allow all 
capabilities specified for passwords 
1 through 6. 

8 Universal Update Password allowing all capabilities 

and access of passwords 1 through 4 
and 6. 

If none of the above listed access codes has been 
input, an appropriate error message will be displayed on the 
CRT and the user will not be permitted access to the data 
base. 


The Basic Data security task will be more coaplex. One 
two dimensional element security matrix will hold all 
information necessary to determine which data elements a 
password has the authority to modify within the basic data 
set. Once it is determined that an element is being 
modified, the security task is referenced to match the 
associated password array index against the SLAHTS Sign^on 
password for validation. If agreement is found, processing 
will continue. However, if the passwords are invalid the 
data base will not be updated and the user will be. notified 
of his error through a message to the terminal. 


2-20 



The Serial Data security task is quite straight 
forward. only the uniwersal update password^ the onnipotent 
password^ and the QAD password have blanket update authority 
on all serial numbered elements with the exception of Serial 
Fidelity Cede and all Class Code 3D items under Groups I and 
IV. In these cases, BSD has sole update authority. SLhHTS 
security requirements are defined in section 5.1, Data Base 
Security of the DRD (reference 3) . 

The Blight Configuration security task allows for 
updates only by ID, Universal Update and Omnipotent 
passwords. 

2.3. 1.4 Data Editing and Va li dat i on . This task is 
required to perform' error detection on the input elements 
for each of the displays. The requirements will appear in 
subtasks and are as follows: 

• Key Data Validation - determines if all key data 
has been input for the requested display. 

• Table Validation - determines if an input value for 
an element matches a value in a specific table. 

• Integer Validation - determines if a value contains 
only numeric characters. 

• Date Validation - determines if a date is an 
allowable date in the MBDDYY format™ It must have 
a one or two digit month itot greater than twelve, a 
one or two digit day of snagnitude determined by the 
month, and a two digit y<^ar. 
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• Pori Validation ** deternines if a value contains 
correct special characters (such as the period) . 

In addition, special data element edits described in the DRD 
will be perfornied. 

2.3. 1.5 Read T ermi nal . This task when loaded will be 
used to read the transaction input data transmitted by the 
user. This task will employ the Input Processor task being 
developed as part of the Common Software package. 

2.3. 1.6 Wr ite Terminal . This task will be used to 
display normal transaction output for any transaction which 
results in user output. This task will employ the Output 
Processor task being developed as part of the Common 
Software package. 

2.3. 1.7 Pagin g. This task displays a page on the 
terminal as specified by the user. The paging instruction 
may be blank indicating first page is requested, or a 
specific page number, or (♦) indicating next page or (-) 
indicating previous page. This task will employ the 
terminal interface support routines being developed as part 
of the common Software package (reference 6) • 

2.3. 1.8 Dat a Ba s e Access . As mentioned prevloasly, 
SLAHTS will afford the user with a wide range of guery and 
update transaction capabilities. To handle these 
transactions, four classes of tasks have been designed: 
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K RETRIEVE - This task will do all data base 

retrievals from the component level on op to the 
repeating group level, 

2. CHANGE - This task will perform modifications to 
the data base at the component level. This 
includes additions, deletions, and changes. 

3. ADD - This- task will add new repeating groups and 
tree structures to the data base. 

4. DELETE - This task will remove repeating groups and 
tree structures from the data base. 

Each transaction may use one or more tasks. Section 
2.3.2 describes in greater detail each task as a function of 
the transaction in which it appears. 

2.3.2 On-Line Processing Subsystem - Transactions 

2. 3. 2.1 Sjqn-On Tra nsa c ti on. The Sign-On Transaction 
will handle the bulk of the SLAHTS's initialization and 
administrative processing. This transaction will have the 
responsibility of validating the user password and assigning 
the data base. In addition, all SLAHTS data base related 
tables will be loaded from disc storage. All necessary 
operations for interfacing the data base management system 
with the assigned data base will be affected. Finally, the 
Sign-On Transaction will either advise the user of any data 
base related anomalies or instruct the user to enter the 
first display code* 
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2.3.2. 2 Ba sic D ata Tran s action . Basic data can be 
displayed and, with proper authority, added, changed or 
deleted using this transaction. By transiitting an 01 froa 
the display code field, the Basic Data form will be 
displayed on the terminal in background intensity. At this 
point, the user enters in the specified fields an Item 
Number, Part Number or Training Part Number as a key data 
element and an authorized action code and affects a full or 
partial screen transmit from the terminal. 

The SLAHTS will first examine the action code field for 
either the retrieval code or the delete code. If either is 
found, the command lines will be scanned for the key data 
elements. Hhen all key elements have been identified the 
following action is initiated: 

1. An action code of R will retrieve and display 
existing Basic Data including Notes and Note Text 
for the specified key element. 

2. An action code of D will cause the key element and 
its associated data structures to be removed from 
the data base. In addition, each time a key 
element is deleted an entry is made in the History 
Data set for each serial data set deleted. 

If neither action code R nor D was encountered, the 
SLAHTS will check for the add or the change action 
code with the following action being taken for a 
find; 
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3. An action code of A will add the key eleaent oc 
elenonts and all Basic Data which has been entered 
on the display to the data base. 

4. An action code of C will allow any of the Basic 
Data elements to be changed, added or deleted, 
provided t|ie pser has a valid password. SLAHTS 
will examine each field of the display for modified 
entries. When a change is encountered, update 
authority is validated and the corresponding field 
in the Basic Data set in the data base is then 
updated. 

In addition to the above outlined capabilities of 
action code C, the user will have the option to modify Mote 
Numbers and Note Text associated with each Basic Data set. 
For this capability, one of the following note action codes 
must be entered in the specified field of the note command 
line. 


1. An action code of AN will attach an existing Note 
to the key element. The user will input the Note 
Number only. 

2. An action code of NN will add a new Mote Number and 
its associated text to the data base. 

3. DN will delete the Note Number reference from the 
key element. If this is the last reference to the 
Note, it will be deleted from the Note Table. 
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4. Action code CN will allow the Note Number Text to 
be changed. 

2. 3. 2. 3 S erj .al D ata Tran saction, Serial data can be 
displayed and, with proper authority, added, deleted or 
changed using this transaction. The Serial Data form may be 
displayed by transmitting an 02 from the display code field. 
Next, a Serial Numbec plus either an Item Number, Part 
Ifunber or Training Part Number and one of the authorized 
action codes may be entered in the corresponding fields. 
Finally, the user may affect the full or partial screen 
transmission from the 'terminal. 

SLANTS will immediately examine the action code field 
for either the retrieval or delete action code. If either 
is found, the command lines will be scanned for key data 
elements. When all have been found, the following action is 
initiated: 

1. An action code of R will retrieve and display 
existing Serial Data for the specified key element. 

2. An action code of D will cause the key element and 
its associated Serial Data to be deleted and a 
Serial History data set will be generated. 

If neither action code R nor D was encountered, the 
SLAHTS will check for an add or change request with 
the following action being taken for a match. 

3. An action code of A will add the Serial Number and 
any other Serial Data on the display to the data 
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base. The Item Number, or Part Number, or Training 
Part Number must alread/ . exist in the data base. 

4. An action code of C will allow any of the Serial 

Data set elements to be changed, added, or deleted. 
Bach field of the display will be examined for 
modified entries from what was transmitted to the 
terminal. Hhen a change is encountered, the 
corresponding data element in the data base is then 
updated after security is checked. 

In addition to the above functions of action code 
C, the action code field of the Shipping-Receiving 
data area is examined for an entry. If blank, 
processing is complete. However, any one of the 
following supplementary action codes nay be used 
when adding new hardware to the system, shipping or 
receiving hardware or querying the Suspense Data 
set ; 

a. An action code of MH (move hardware) will cause 
the specified Building Location Quantity and 
Cabinet Location Quantity to be decremented by 
the amount specified under the shipping data. 
Also, the Issue Date, Destination and Quantity 
specified under Shipping Data will be moved 
respectively to Last Issue Date, Building 
Location and Quantity of the Serial Data set. 
Finally, a Suspense Data set will be created 
containing all pertinent shipping data. This 
data set will be used as a data base shipping 
invoice which must agree with the follow up HH 
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(receive hardvare) transaction at the 

i 

destination location. The authority docunent 
■ust be entered for lot-nunbered data. 

b. The BH action code is also used in conjunction 
vith action code C of the coamand lines. If 
the Building Location and Quantity specified 
under Receiving Data matches the Suspense Data 
set for the particular Serial Data, then the 
Cabinet, Quantity and transfer date specified 
under Receiving Data are moved into the 
analagous data values of the particular Serial 
Data set. For lot~numbered items, the Shipping 
Authority Document will be used to 
differentiate between Suspense Data set entries 
and must therefore be entered. 

The final action taken will be for the Suspense 
Data set to be removed and a History Data set 
entry generated. 

c. An action code of AH (add hardware) can be used 
with both command line action codes A and C. 

Vhen used vith the code A, the add hardware 
transaction will create the initial history 
entry. 

When used with the action code C, an additional 
history entry will be made to reflect the 
addition df new lot numbered items. 


2-28 



d. The action code CT (cancel tracking) nay be 
used with coanand line action code C to create 
a final history entry indicating the particular 
serial nuabered item is to no longer be tracked 
by the SLAHTS. 

If lot-numbered items are being processed, the 
specified Building Location Quantity will be 
decremented by the indicated amount. However, 
if the remaining lot-numbered quantity is zero, 
the element will no longer be tracked by the 
SLAHTS and will be deleted from the data base. 

e. The action code BS (retrieve suspense file 
entry) can only be used with the command line 
action code B. In this case, the user must 
also input the Authority Document. This 
command will cause the Suspense Data entry for 
the specified Serial Data set to be removed. 

In addition, the Building Location and related 
Cabinet Quantity values will all be incremented 
by the amount specified on the Suspense Data 
set entry to cancel the effects of this 
particular move (HH) . Finally, the Suspense 
Data set entry for that transaction will be 
deleted. 


2 . 3 • 2 - 4 Fli ght Con figurati o n Definit i on Transa ction . 
The Flight Configuration Definition for some particular Item 
Humber or Part Number within some specified Flight Number 
'"an be displayed and, with proper authority, changed or 
deleted by means of this transaction. To retrieve the 
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Flight Configuration Definition forn, an 03 nust be 
transnitted from the display code field. At this point, the 
liser enters the action code, the Flight Number plus either 
the Item Number or Part Number as key data elements. A full 
or partial screen may then be transmitted. 

The SLANTS will first examine the action code field for 
either the retrieval, element deletion or flight deletion 
codes. If either of the three is found, the command lines 
will be scanned for the Key data elements. Hhen all have 
been recognized, the following action is initiated: 

1. An action code of R will retrieve and display the 
existing flight configuration for the specified key 
elements. 

2. An action code of D will remove the Item Number 
attachment from the Flight Number. Also, all 
Flight Configuration Data for this item will be 
purged from the data base. 

If neither the R, nor D action code was specified, 
the SLANTS will check for the add or change action 
code with the following action to be taken for a 
match: 

3. An action code of A can be used to add some 
specified Item Number to an existing Flight. 
However, if the Flight Number does not exist, a new 
Flight Configuration Definition will be created. 
Also, if the user specifies a Part Number as one of 
the key data elements, the program will retrieve 
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the Basic Data set associated with the Patt Nuaber 
and extract the Item Nunber to use whiXe assigning 
a Flight Nuaber to the key data eleaent. 

4. An action code of C will allow any of the 

configuration data to be changed# added or deleted. 

Initially the first 8 lines of itea level related 
data will be exaained for updates. If encountered# 
the changes to the data set will be aade as 
specified. 

Furthermore, Launch, Orbit and Return coluans will 
also be examined for updates. If modifications are 
encountered# the update will be made to the related 
data sets. If the Location, Quantity data columns 
have new entries, the associated data set will be 
updated to reflect the changes. 

Finally, the program will scan the SLCN data fields 
for input. If found, the data will extracted 
from the display and entered in the SLCN data sets 
associated with the specified Flight Number. 

2 . 3 . 2 . 5 F li ght Location / Serial C o nfiguration D ata 
Tra nsactio n. Using this transaction, serial numbered data 
can be displayed by Launch Location and Quantity within the 
Flight Nuaber. The display form may be retrieved by 
transmitting an 04 from the display code field. The user 
nay now enter the Flight Number and Item Number or Part 
Nunber as key data elenents. Depending on the action code# 
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either a full or partial screen transnlssion nay be 
affected. 

The SLAHTS will initially exaaine the action code field 
for the retrieval code. If found, the conaand lines will be 
scanned for the key data elements. When recognized, the 
following action is taken. 

1. Action code K will retrieve and display all Serial 
Numbers having the specified Part Nuaber or Itea 
Number for the specified Plight Number. Serial 
Numbers will be tracked for only the launch phase 
locations. 

If SLANTS has not found the R action code, a check 
will be made for the C action code. If found the 
following path will be taken. 

2. An action code of C will allow input of SLCN data 
and any of the serial numbers to be changed, added 
or deleted provided the user has the necessary 
authority. SLANTS will examine the Serial Numbered 
fields residing under the Location/Qty fields which 
were for display only. If new information is 
encountered, the Serial Numbered data will be 
assigned to the specified Launch Location. 

2 . 3 . 2 • 6 F light SLC N Hist ory Displ ay Transaction . 
Stowage List Change Notices for any Item Number within some 
specified Plight Number may be displayed and, provided the 
user has proper authority, changed or added. To retrieve 
the form, an 05 must be transmitted from the display code 
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£ield. Once the form is displayed, the user aay input the 
Plight Number and l.tem Number as K<^y data eleaents and one 
of the authorized action codes. Either a partial or full 
screen may nov be transmitted. 


SLANTS will first check the action code field for the 
retrieval action code. If present, both command lines will 
be scanned for the key data. If all necessary Xey data is 
present, the SLANTS will perform the following: 

1. Action code R will display, sequenced by date, all 
SLCN data associated with the two key data 
elements. 

If an R is not found, the SLANTS will check for 
either the add or change action code with the 
following action being taken for a match: 


2. Action code A will first verify that no previous 
SIGN’S have been input for the specified key 
elements. If verification is positive, the new 
SLCN data will be entered as a new data set. 

3. If an action code of C has been input, SLANTS will 
scan the display for new additions, deletions, or 
changes to the current SLCN History Data set. Any 
changes encountered will be made to the data base. 

2 . 3 . 2 . 7 Function/Svstc m Cl assi fi ca tion Quer y 
Ty ji^Sci^ction. All items having the specified Function/System 
classification for the particular Plight Number may be 
displayed, alphabetically seguenced by Procedural 
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Nonenclature One, The display form itself «ay be retrieved 
by transnitting an 06 froii the display code field. Next, 
the Flight Hunber and Fanction/Systea Classification code 
Hill be input as key eleaents with an action code of C being 
assumed, upon transmission of the coamand lines, SLANTS 
will begin scanning for key data elements. If the necessary 
key elements are present, SLANTS Hill retrieve and display 
all system hardnare having the Punction/System class code 
specified. 

2. 3. 2. 8 Locati on I nventory Qu ery Transactio n. The 
complete inventory for some particular on board Stovage 
Location on any specified Flight can be displayed using this 
transaction. By transmitting the 07 from the provided 
display code field, the Location Inventory Query form nay be 
retrieved for input. The user will enter Flight Number, 
Phase and Location with an action code of R being assumed. 

Upon transmission of the screen, SLANTS will scan the 
command lines for the key data elements and when found will 
display all on board hardware residing in the specified 
stowage location. 

2 . 3 . 2 . 9 Fli g ht C onf iau pa tion Cha nge Q uer y Transaction . 
All Flight Configuration Changes which have been applied to 
the data base within some specified time frame can be 
displayed using this transaction. By transmitting the 08 
from the provided display code field, the Flight 
Configuration change Query form may be retrieved. The user 
must enter Flight Number and Delimiting Dates as key data 
elements. No action code is necessary. 
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After transnission of the screea, SLAHTS iiill examine 
the first two comnand lines for the key data. Next, for tho 
specified Flight Number, a table will be built for all 
SLCN*s falling within the given tine period. This table 
cannot exceed 500 SLCN nunbers. In the event this nunber is 
exceeded, the user will be requested to supply more 
restrictive dates. 

when the table is conpleted, it will be output to the 
terninal one page at a time. It will be sequenced by Item 
Nunber and subsequen^ed by SLCN Number. 

1 

2.3.2.10 Serial Histo r y Qu er y Trans a ctio n. Using this 
transaction, all history data entries which are stored in 
the data base for the specified Serial Number and Item 
Nunber or Part Number or Training Part Nunber nay be 
displayed. By transmitting an 09 from the display code 
field, the Serial History Query form may be retrieved. At 
this point the user may enter the Serial Number and an Item 
Nunber, a Part Number or a Training Part Number as key data 
elements. No action code entry is needed. 

After the screen is transmitted, SLAHTS will scan the 
first two command lines for key data. Using this key data, 
the data base can be queried with Basic Data elements. 

Serial Data elements and the History Data set for the key 
element being returned for display in order of Hardware 
transfer date. 

2.3.2.11 Si gn-Off T rans action. The SLAHTS Sign-Off 
transaction will be charged with closing the data base and 
ending the data base management system. Also, the necessary 
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KBONOS control coaoand will be issued to log the user off 
the operating systeo. 

2 .3 .3 Batch Processing Subsystea 

1 

This subsysten will consist of. three stand-alone 
programs as listed below: 

• Batch Processing and Report Program 

« QA Data Base Load Program ‘ 

• History processing Program 

The following sections will describe the nodules 
stating the method employed, the input required, the 
processing performed, and the output generated. All 
sections except the final two, are part of the Batch 
Processing and Report Program. The definition of Type I and 
II reports are given in section 2.1. 3.5, Batch Processing. 
Reports are generated either by System 2000 Procedure 
Language Interface with FORTRAN application code (PlI/FTN) 
or by System 2000 Report Writer (S2KRW) . 
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2.3.3. 1 Stowa qf List Report 


SLAHTS Data Dase 
Input Card Image 

Pr oce ssing : This module is of Type I (PLI/FTN) . 

Processing rules are given in the Detailed Requirements 
Document for SLAHTS. If Stowage List date is input, then 
upon completion of the Stowage List Report, this module will 
transfer control to the Stowage List Change Notice Report 
Module lor further processing and output of data. 

Ou tp ut; The output format for this report is given in 
the DRD for SLAHTS. The note data printed at the bottom of 
the page are tlose note numbers referenced on that page 
beginning with A, B, or C and the corresponding note text. 
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2 • 3 . 3 . 2 Lggi sticf^ Manage me nt Report rxtea Lev eU . 

SLAH1S Data Base 
Input Card Image 

j ^y o cessin a; This module is o£ Type II (S2KBH) • Only 
the orbiter Plight Hardware will be processed for the 
report. Additional processing rules are given in the SLAUTS 
DRD. 

Out put ; The DRD for SLAHTS displays the output formatf 
figure 4. 2. 2. 2^ 

2 . 3 . 3 . 3 j^g gj-s tiy s Wana gene pt Report ^Se r ^a^^ Haibec 

In p ut ; SLAHTS Data Base 
Input Card Image 

Pr o cessi ng; This module is of Type II (S2KRii) , 
utilizing the Report Writer feature of System 2000. 
Processing rules are given in the SLAHTS DRD. 

Output ; Report output generated by this nodule is 
given in the DRD for SLAHTS, figure 4. 2.2.3 • 
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2 . 3 . 3 . 4 Prepack Procedure Report . 

Ingut; SLAIITS Data Base 
Input Card Imaye 

Proc es sing: This module is Typ<^ I (PLI/FTN) and the 

rules for processing the data ace given in the Detailed 
Regii iremonts Document for SLAHTS, 

O ut p ut ; Format for this report is given in the DRD for 
the SLAHTS, figure 4.2.2. 4. 

2. 3. 3. 5 St ow ag e Lpcker Rep ort. 

Input: SLAHTS Data Base 

Input Card Image 

££2£2.§SiEL3 • The processing rules for generating the 
output are given in the DRD for SLAflTS. This module is of 
Type I (FTN) . 

output; The DRD for SLAHTS has a sample of the output 
format# figure 4. 2.2.5. 
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2 • 3 • 3 . 6 M as ter p ond R o om Storage L ist • 

Input ; SLAHTS Data Base 
Input Card Inage 

Processing: The data selected for this report has a 

Class Code of 1A# IB, and 2. Additional processing rules 
are discussed in the DRO. This nodule is of Type II 
(S2KRN) . 

Outpu t: The output will contain page breaks for each 

building. The DRD for SLAHTS has figure 4.2.2.6 giving the 
output f ornat. 

2 • 3 . 3 • 7 Post Flight Dispositi on Report • 

Input ; SLAHTS Data Base 
Input Card inage 

Processing ; This is a Type I (PLI/FTN) nodule. The 
processing rules are given in the DRD for SLAHTS. 

Out p ut ; The output fornat is contained in the Detailed 
Beguirenents Docunent for SLAHTS, figure 4. 2.2. 7. 


2-40 



2 . 3 . 3 • 8 Nomen cl atur e D efinition K ep ort. 

irifiut: SLANTS Data Dase . 

Input Card Image 

Pr oc essing; This module is of Type II (S2KKU) • The 
report will include Orbiter Flight Hardware only (Item 
Number exists) . Additional processing rules are given for 
the DFD for SLAHTS. 

Qut|)ut: This module will result in the Nomenclature 

Definition Report; format given in the DRD. 

2 . 3 « 3 • 9 Alphabetical Proced ural Nome ncl(^ture Rep or t . 

SLAHTS Data Base 

Input Card Image 

P rocessing ; This module is Type I (PLI/FTN) • The 
rules for special processing are given in the DRD for 
SLAHTS. 

Out put ; This module generates the Alphabetical 
Procedural Nomenclature Report, format given in figure 
4.2. 2. 9 of the DRD for SLAHTS. 
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2 • 3 . 3 . 1 0 Flight Equ ipae nt Serial Bepoy t 


I npv>it ; SLKHTS Data Base 
Input Card Inage 

P rocessing : This module is Type I (PLI/FTDi) • Rules 

for processing are given in the ORD for SLAUTS. 

Outp ut ; The Flight Equipment Serial Nuaber Report is 
generated by this module. Format is given in figure 
4.2., 2.10 of the DRD for SLAHTS, 

2.3.3.11 Flight Location/ Eg ui pme n t Report . 

Inpu t; SLAHTS Data Base 
Input Card Image 

Pr o cessi ng; This module is Type I (PLI/FTN) . 
Processing rules are given in the ORD for SLAHTS. 

Outpu t; This nodule generates the Flight 
Location/Eguipaent Report; foraat given in figure 4.2.2.11 
of the DRD for SLAHTS. 
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2.3.3.12 Inf ligh t Transfer List Hoport . 

Inp ut ; SLAHTS Dat.i Base 
Input Card Image 

Processing; This module will use Type I (PLI/PTN) . 
Processing rules are given in thesDRD for SLAHTS. 

Outp ut ; The Inflight Transfer List Report will be 
output from this module. Format is given in figure 4.2.2.12 
of the DKD for SLAHTS. 

2.3.3.13 Res po nsib le Organizat io n L ist. 

Injjut: SLAHTS Data Base 

Input. Car.d Image 

Process in g ; This module is of Type II (S2KRW) . Rules 
for processing have teen listed in the detailed roguirements 
document for this system. 

O utpu t; This module results in the Responsible 
Organization List. Figure 4,2.2.13 for the PHD for SLAHTS 
displays the format. 
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2.3.3.14 She lf Life Expi r ation List • 

I nput : SLANTS Data Base 

Input Card Image 

Pro cessi ng: This module is Type II (S2KRH) • Details 

of the processing rules are available in the DRD for SXAHTS. 

Output : Shelf life Expiration List is output from this 

module. Format is shown in figure 4.2.2.14 of the DRD for 
SLANTS, 

2*3.3.15 Flight Data Rep rod oction . 

In£Ut: SLANTS Data Base 

Input Card Image 

Proces sing : This module is Type I (PLI/PTN) and will 

duplicate an existing Flight Configuration in the data base 
for every Flight Data Reproduction card read. It will copy 
an existing flighty changing the flight number. At 
completion# both flight configurations will be in the data 
base. 

output: A new flight configuration entry in the data 

base. 
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2,3.3.16 Annual Inventory List , 

Inp ut ; SLAHTS Data Base 
Input Card Imaqe 

Pro cessi ng ; This nodule is Typo IT (S2KHH) . 

Processing rules are given in the DRD for SLAHTS. 

Outp ut ; The Annual Inventory List is generated by this 
nodule. Report format is given in figure 4,2.2.16 of the 
DRD for SLAHTS. 

2.3.3. 17 FjiJlc t i o n^S^s t em_C 1 assi f icg> tiofi^Re^or t . 

Input: SLAHTS Data Base 

Input Card Image 

processing rules for this nodule are 
detailed in the requirtnents document for SLAHTS, The modulo 
is Type I (PLI/FTN) . 

Out put : Format for the Function/System Classification 

Report generated by this module is given in figure 4.2.2,17 
of the DRD for SLAHTS. 
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2.3.3.18 Stow age List Ch a nge Notj|.ce • 

Input s SLAHTS Data Base 
Input Card Inage 

g coc e ^sin o; This nodule is Type X (PLI/FTN) . 

Processing rules are listed in the DHO for SLAHTS. 

Output ; This nodule results in the Stowage List Change 
Notice Report; foraat given in figure 4.2.2.18 of the DBD 
for SLAHTS. 

2.3.3.19 Equ ipment Class 3 Processing and R e por t. 

Input ; SLAHTS Data Base 
Input Card Inage 

Processing ; This nodule is Type II (S2KBH) • Detailed 
processing rules are given in the DEO for SLAHTS. Only 
those itens placed in Class Code 3A category since the last 
Egolpnent Class 3 Report was generated will be output by the 
nodule. 

O utput ; The fornat of the Equipnent Class 3 Beport is 
shown in figure 4.2.2.19 of the DRO for SLAHTS. 
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2.3.3.20 Training Hardwar e Requireaents and S tatus . 

Infiiit; SLAHTS Data Base 
Input Card Image 

Processing; This module is Type II (S2KRH) . All 
processing rules are described in the DRD for SLAHTS* 

ou tput; This module generates the Training Hardware 
Requirements and Status Report. Format for the report is 
given in figure 4.2.2.20 of the DRD for SLAHTS. 

i 

2.3.3.21 Trainin g Ha rdwa re Master Inv ent ory Report. 

Inp ut ; SLAHTS Data Base 
Input Card image 

Processing ; This module is Type II (S2KHW) . Rules for 
processing the report are given in the DRD for SLAHTS. 

Out pu t ; The Report 21 Module generates the Training 
Hardware Master Inventory Report. The format is given in 
figure 4.2.2.21 of the DRD for SLAHTS. 
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2«3.3«22 Suspen se File Repo yt, 

Input; SLAHTS Data Base 
Input Card laage 

Proces sing; This aodule is Type II (S2KRH) • It vill 
consist of two sections: (1) produces the actual Suspense 

File Report and (2) produces a cross-reference between Itea 
Nunber and Part MuBbei;:. 

Out put; This module generates the Suspense File Report 
and attaches a cross-reference listing to the end of the 
report* The format is given in the DBD for SLAHTS. 

2*3.3.23 Data Elem ent Ed4t Table Report . 

Inp ut ; SLAHTS Data Base 

Input Control Card Image 

Proce s sing ; The module is Type II (S2KRH) . All 
current values in the edit tables will be listed. 

Ou tpu t: Report format is given in the ORO for SLAHTS, 

figure 4.2.2. 23. 
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2.3.3.24 Note list 


Input; SLAHTS Data Base 

Input Control Card Image 

Proce ss i ng ; This module is Type II (S2KBH) . 

Processing will be divided into two sections; (1) create 
the Note List Report and (2) generate a cross-reference 
list, if required, at the end of the report. Rules 

regarding processing are given in the DRD for SLAHTS. 

i 

Output; Report format is given in the DRD for SLAHTS, 
figure 4.2.2.34. 

2.3.3.25 Bat ch P roce ssing E xecutive . 

Input: SLAHTS Data Base 

Input Cards 

P ro cessing: This module is the initialization program 

for the Batch Processing Subsystem. The executive will 
process calls to the Type I subsystem modules and will 
establish a KRONOS procedure file to process module Type II. 

O ut put; (1) Reports generated by calls to Type I 
modules and (2) a KRONOS procedure file which will vary as a 
function of the reports or processes requested on input 
cards. 


2-49 



2.3. 3.26 FI De leti on_.Mod uig . 


Inpu t; SLA MTS Data Base 
Input Cards 

Proc essing ; This nodule is Type I (PLI/FTN) • Given 
the Plight Number, the nodule, will delete the Flight Number 
and all of its associated configuration data from the data 
base. 


Qu^ pgt ; A data base which has been updated to reflect 
the deleted Plight or Plights. 

2 • 3 • 3 . 27 Edit lab^- e .Ppda te Mg duJ re . 

Inp ut ; SLAHTS Data Base 

Edit Table Input Card Image 

ggpee gg ing; This module will process updates to the 
data base edit tables provided the user has proper 
authority. It is Type I (PLI/FTN). 

Output; Update the Edit Tables in the SLAHTS Data 

Base. 

2.3.3.28 M ic ro fi lm O utput M odule. 

Inp ut; Output File 

gr oepg si nq ; This nodule accepts as input an output 
file generated by other modules. This file will contain all 
reports requested on nicrofilm. Using the HPfilNT Utility, 
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this module will generate a tape formatted for producing 
microfiche from the RTCC COM facility. It is Type I 
(PLT/FTN) . 

Output; Tape formatted for producing microfiche. 

2.3.3.29 Mass Prop e rties Ta pe , Module . 

Input; SLAHTS Data Base 
Input Card Image 

Pyoce gs inq; This module is Type I (PLI/FTU) . Rules 
for processing have been given in the DRD for SLAHTS. 

O utpu t ; One seven trach, BCD, loose equipment data 
tape acceptable as input to the Mass Properties Program. 

2.3.3.30 Histo ry P roce ss ing Pr ogram . 

In put; SLAHTS Data Base 
Input Card Image 

Processing; This program is Type I (PLI/FTN) and will 

• I 

have these functions: (1) generate an Item History Report, 

(2) create an Item Number/Part Number cross reference report 
for those entries having an Item Number, and (3) reduce the 
history data sets for each Serial/Lot Number to a minimum of 
ten (reference SLAHTS DRD section 5.2) . In generating the 
history report, a permanent file will be saved to later be 
purged by the data base administrator upon confirmation that 
the report was correctly processed. 
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Processing rules for this report are given in the DRD 
for SLAHTS, 

O ij|t put : The output format for the Item History Report 

is given in figure 4.2.2.15 of the DRD for SLAHTS. 

2 • 3 • 3 • 3 1 QA Data Ba se L oa d Program • 

Inp ut; SLAHTS Data Base 

Converted Bonded Storage Master File With 
Editing 

Proc e ssing ; This program. Type I (PLI/FTN) will read 
an intermediate tape (Section 3.1), place the accepted data 
values into a value-string format, and create a file 
reflecting the newly accepted entries from the Bonded 
Storage Master File. The SLAHTS data base will then be 
loaded with the values on the file. 

The preprocessing required for the data elements in the 
Bonded Storage Master File is listed in the SLAHTS DRD. 

Out put; A data base containing data values input from 
the Bonded Storage Master File. 
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3.0 IMPLEMENTAT ION 
3.1 DATA BASE ESTABLISHMENT 

Data base establishment will require two major efforts; 
the creation of the data base structure itself and the 
conversion of the current data format into one which the 
SLAHTS can manipulate. 

The data base structure for the SLAHTS will be System 
2000 (see section 2.2). Creation of the data base structure 
will bo accomplished through Define Module concepts now 
available under the System 2000 data base management system 
on the CYBEH computer. 

The data for the SLAHTS data base will consist of the 
inventory in the master file for the Bonded Storage System. 
This file is now maintained on tape and is updated via batch 
processing on a UNIVAC 1100 series computer. As a result, 
the implementation effort will include the generation and 
testing of software to convert the present data base into a 
format that the SLAHTS can manipulate while operating on the 
CYBEfi computer. 

The conversion software will consist of a UNIVAC COBOL 
program which will copy each 12 word entry descriptor from 
the Bonded Storage Item Master onto a tape file suitable for 
use on the CYBER. Each entry will then be edited to conform 
to the SLAHTS specifications. Finally, the entire file will 
be reorganized and reformatted into a suitable format which 
can be loaded into the System 2000 data base by means of a 
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single PLI program 
nodule.) 


(See 2.3.3. 31 QA Data Base Load 


3.2 OPERATIONAL STAGES 
3.2.1 Phase X 

The SLAHTS vill be developed as a two phase system. 
Phase I will support two SLAHTS users, SB&QA and ESD. The 
functional areas developed in Phase I are listed below: 

Users: SBSQA, E&D 

Functions to be implemented. 

• BASIC DATA SET PROCESSING 

• SERIAL DATA SET PROCESSING 

• HISTORY PROCESS ROUTINES 

• SECURITY 

• EDIT TABLE USE AND MAINTENANCE 

• TERMINAL INTERFACE FOR HAZELTINE 2000 AND 4000G 
TERMINALS 

• SUSPENSE FILE PROCESSING 

• QAD DATA BASE LOADING 

• SFfiQA AND E6D BATCH REPORTS 

The following reports and display nodules will be 
completed in Phase X: 

fiiSPL A Y S 

• 01 Basic Data 

• 02 Serial Data 
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• 09 Serial History Query 
I^ICH^BEPORTS 

• 06 Haster Bond Room Storage List 

• 13 Responsible Organization List 

• 14 Shelf Life Expiration List 

• 15 History Report 

9 16 Annual Inventory List 

• 19 Equipment Class 3 Report 

• 20 Training Stowage Requirements and Status 

I 

• 21 Training Hardware Master Inventory Report 

• 22 Suspense File Report 

• 23 Data Element Edit Table 

• 24 Note ‘List ' 

3*2,2 Phase II 

Phase II will fulfill all requirements specified in the 
SLANTS DRD. The functional areas developed in Phase II are 
listed below: 

Users: POO, FOD, SR&QA, BSD 

Functions to be implemented. 

• FLIGHT CONFIGURATION TRACKING 

• SLCN TRACKING 

• MASS PROPERTIES TAPE INTERFACE 

« PROCEDURAL NOMENCLATURE TRACKING 

• POO 6 FOD BATCH REPORTS 
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The following reports and display nodules will be 
coapleted in Phase II. 

• 03 Plight Configuration Definition 

• 04 Flight Location/Serial Configuration Data 

• 05 Plight SLCN History 

• 06 Punctlon/System Classification 

• 07 Location Inventory Query 

• 08 Flight Configuration Change Query 

BATCH REPO RTS 

• 01 Stowage List Report 

• 02 Logistics Hanagement Report (Item Level) 

• 03 Logistics Management Report (Serial Number 
Level) 

• 04 Prepack Procedure Report 

• 05 Stowage Locker Report 

• 07 Post Flight Disposition Report 

• 08 Nomenclature Definition Report 

• 09 Alphabetical Procedural Nomenclature Report 

• 10 Flight Equipment Serial Report 

• 11 Flight Location/Eguipment Report 

• 12 Inflight Transfer List Report 

• 17 Functional/System Classification 

• 18 Stowage List Change Notice Report 
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APPENDIX A 


BATCH PROCESSING INPUT CARD 
FORMATS 





This appendix describes the input cards necessary to 
select SLAHTS batch reports or batch processing. Each 
report requires a particular input card forwat. The card 
colunns are specified for the input variables. The comments 
column will state whether the variable is required input or 
optional. The users guide will describe additional control 
cards necessary to submit a job. 




TITLE: STOWAGE LIST REPORT CARD FORHAT 


TYPE: 

Batch Report 0'1 

Card 




Item 


Card 




liaflbgg 

Name 

Columns 

Size 

Type 

Comments 

1 

Report Number 

1-2 

2 

N 

Required - 
must be 01. 

2 

Flight Number 

3-7 

5 

A/N 

Required. 

3 

Sort Option 

8 

1 


Required - 
may be 0, 
1, or 2. 

4 

Stowage List 

9-14 

6 

N 

Optional - 


may be date 
ov blanlc. 


TITLE: 

TYPE: 

LOGISTICS MANAGEMENT REPORT (ITEM 
Batch Report 02 Card 

LEVEL) 

CARD FORMAT 

Item 

1 

Name 

Report Number 

Card 

Columns 

1-2 

Size 

2 

Type 

N 

Coaments 
Required - 


must be 02. 


TITLE; LOGISTICS MANAGEMENT REPORT (SERIAL NUMBER LEVEL) 
CARD FORMAT 

TYPE: Batch Report 03 Card 


Item 


Card 



Nuafaer 

Name 

Columns Size 

Type 

Comments 

1 

Report Number 

1-2 2 

H 

Required - 





must be 03 


TITLE: PREPACK PROCEDURE REPORT CARD FORMAT 


TYPE: 

Batch Report Oh 

Card 




Item 


Card 




Humber 

Name 

Columns 

Size 

Type 

Comments 

1 

Report Number 

1-2 

2 

N 

Required - 






must be 04 

2 

Flight Number 

3-7 

5 

AANNN 

Required. 



TITLE: 

STOWAGE LOCKES 

REPORT CARD FORMAT 

TYPE: 

Batch Report 05 

Card 


Item 


Card 




llttaber 

Name 

Columns 

Size 


Comments 

1 

Report Number 

1-2 

2 

N 

Required - 
must be 05. 

2 

Flight Number 

3-7 

5 

A/N 

Required 

3 

Phase Indicator 

8 

1 

A 

Optional - 
may be L, 0, 
or Blank. 


TITLE: WASTES BOND ROOM STOBAGE LIST CARD FORMAT 

TYPE: Batch Report 06 Card 


Item 


Card 



UUll!S£ 

Name 

Columns Size 

Type 

Comments 

1 

Report Number 

1-2 2 

N 

Required - 
Must be 06 



TITLE: POST FLIGHT DISPOSITION REPORT CARD FORMAT 



TYPE: 

Batch Report 07 

Card 




Item 

* 

Card 




Humber 

Name 

Columns Size 


Comments 

- 

1 

Report Number 

1-2 2 

N 

Required - 






must be 07. 


2 

Flight Number 

3-7 • 5 

A/N 

Required. 

- 

TITLE: 

NOMENCLATURE DEFINITION REPORT 

CARD FORMAT 


TYPE: 

Batch Report 08 

Card 





Item 

yumber 

Name 

Card 

Columns 

Size 


Comments 


1 

Report Number 

1-2 

2 

N 

Required - 
must be 08. 
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TITLE 


ALPHABETICAL PROCEDURAL 
FORMAT 


TIPE: Batch Report 09 Card 


Item 


Card 


Name 

Columns 

1 

Report Number 

1-2 

2 

Flight Number 

3-7 

3 

Sort Option 

8 


TITLE: FLIGHT EQUIPMENT SERIAL 

TYPE: Batch Report 10 Card 

Itea Card 

Muaber NSl® Col umri S 

1 Report Number 1-2 

2 Plight Number 3-7 


NOMENCLATURE REPORT CARD 


TITLE; FLIGHT LOCATION/EQUIP WENT REPORT CARD FORMAT 
TYPE: Batch Report 11 Card 


Item 


Card 





Name 

Columns 

Size 


Comments 

1 

Report Number 

1-2 

2 

N 

Required - 
must be 11. 

2 

Flight Number 

3-7 

5 

A/N 

Required. 

3 

Phase Indicator 

V 

8 

1 

A 

Optional - 
may be L, 0 
R, or Blank 


TITLE: INFLIGHT TRANSFER LIST REPORT CARD FORHAT 

TYPE: Batch Report 12 Card 


Item 

Number 

Name 

Card 

Columns 

Size 


Comments 

1 

Report Number 

1-2 

2 

N 

Required - 

2 

Flight Number 

3-7 

5 

A/N 

must be 12 
Required. 
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TITLE: BESPONSIBLB OBGANIZATION LIST CABD FOBHAT 

TYPE: Batch Report 13 Card 


Item 


Card 



lumber 

Name 

Columns 

Size 

Type Comments 

1 

Report Number 

1-2 

2 

N Required - 

must be 13. 


TITLE: SHELF LIFE EXPIRATION LIST CARD FORMAT 

TYPE: Batch Report 14 Card 


Item 


Card 




Number 

Name 

Columns 

Size 

lis& 

Comments 

1 

Report Number 

1-2 

2 

N 

Beguired - 
must be 14 
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TITLE 


FLIGHT LOCATION/EQUIPMENT REPORT CARD POHBAT 


TYPE; 

Batch Report 11 

Card 




Item 


Card 





Name 

Columns 

Size 


Comments 

1 

Report Number 

1-2 

2 

N 

Required - 




» , 


must be 11. 

2 

Flight Number 

3-7 

5 

A/N 

Required. 

3 

Phase Indicator 

1 

8 

1 

A 

Optional - 
may be L, 0, 
R, or Blank. 


TITLE: 

INFLIGHT TRANSFER LIST 

REPORT 

CARD FORMAT 

TYPE; 

Batch Report 12 

Card 




Item 


Card 




Number 

Name 

Columns 

Size 


Comments 

1 

Report Number 

1-2 

2 

N 

Required - 






must be 12. 

2 

Flight Number 

3-7 

5 

A/N 

Required. 



TITLE: 

TYPE; 

* 

Item 

Baifegi 

1 


TITLE: 

TYPE: 


Item 

pumber 

1 


BESPONSIBLE ORGANIZATION LIST CARD FORMAT 
Batch Report 13 Card 



Card 



Name 

Columns 

Size 

Type Comments 

Report Number 

1-2 

2 

N Required - 

must be 13 


SHELF LIFE EXPIRATION LIST CARD FORMAT 
Batch Report 14 Card 

Card 

Naig Colum ns Size T^£e Comment s 

Report Number 1-2 2 N Required - 

must be 14. 



TITLE: FLIGHT DATA BEPHODUCTION 


TYPE: Flight Data Beproduction Card 


Item 


Card 




Number 

Name 

Columns 

Size 

Tjt£e 

Comments 

1 

Identifier 

1^2 

2 

N 

Beguired - 
must be 15. 

2 

Flight 

3«7 

; 5 

A/N 

Beguired - 
must be an 
existing 
flight in 
the data 
base. 

3 

New Flight 

8-12 

5 

A/N 

Beguired - 
must not be 
an existing 
flight. 


TITLE: 

ANNUAL INVENTORY 

LIST CARD 

FORMAT 



TYPE: 

Batch Report 16 

Card 




Item 


Card 





Name 

Columns 

Size 


Comments 

1 

Report Number 

1-2 

2 

N 

Beguired - 






roust be 16 



TITLE: 

TYPE: 


Item 

l!Si£ber 

1 

2 


TITLE : 
TYPE: 


Item 

JUB&er 

1 

2 

3 


FUNCTION/SYSTEM CLASSIFICATION CARD FORMAT 
Batch Report 17 Card 


Card 




Name Columns 

Size 

Tjtpe 

Comments 

Report Number 1"-2 

2 

N 

Required - 




must be 17 

Flight Number 3-7 

5 

A/N 

Optional. 


STORAGE LIST CHANGE NOTICE REPORT CARD FORMAT 


Batch Report 18 

Card 





Card 




Name 

Columns 

Size 

Type 

Comments 

Report Number 

1-2 

2 

N 

Required - 





must be 18 

Flight Number 

3-7 

5 

A/N 

Required. 

Selection Date 

8-15 

6 

. N 

Optional. 



, 




A-10 



EQUIPHENT CLASS 3 BEPORT CARD FORMAT 


TITLE; 


TYPE: Batch Report 19 Card 


Item 
y um ber 
1 


Card 

C olumns 

Report Number 1-'2 


Size Tub© Comments 
2 N Required - 

must be 19. 


TITLE: TRAINING HABCHARE REQUIREMENTS AND STATUS CARD FORMAT 

\ 

TYPE: Batch Report 20 


Ittjm 


Card 



fi3S«^g£ 

Name 

Columns 

Size 


1 

Report Number 

1-2 

2 

N Required 

must be 



TITLE: TRAINING HARDWARE MASTER INVENTORY REPORT CARD FORMAT 


TYPE: Batch Report 21 Card 


Itep 


Card 






Colunns 

Si£e 


Coaments 

1 

Report Nunber 

1-2 

2 

N 

Required - 
must be 21 


TITLE: 

SUSPENSE FILE REPORT CARD 

FORMAT 



TYPE: 

Batch Report 22 

Card 




Item 


Card 




Number 

Name 

Columns 

Size 

Type 

Comments 

1 

Report Number 

1-2 

2 

N 

Required - 
must be 22 

2 

Class Code 

3 

1 

N 

Required - 
must be 0 
1. 

Required - 

3 

Sort Option 

4 

1 

N 


Must be 0 or 



TIT-T.E: DATA ELEMENT EDIT TABLE BEPORT CARD FORMAT 

TYPE; Batch Report 23 Card 


Item 


Card 




Number 

Name 

Columns 

Size 


Comments 

1 

Report Number 

1-2 

' 2 

N 

Required 
must be 


:l / 

TITLE; NOTE LIST CARD FORMAT 

TYPE: Batch Report 24 Card 

Item Card 



Name 

Columns 

Size 

Type 

Comments 

1 

Report Number 

1-2 

2 

N 

Required - 
must be 24. 

2 

Range Option 

3-4 

2 

A 

Optional 

3 

Cross-Reference 

Option 

! 5 

1 

N 

Required - 
may be 0 or 

1. 



TITLE: 

FLIGHT DELETION 





TYPE: 

Flight Deletion 

Card 




Itea 


Card 




lUEh&i 

Name 

Columns 

Size 

IlPe 

Comments 

1 

Identifier • 

'l-2 

2 

N 

fieguired - 
must be 26 

2 

Flight 

Number 

3-7 

5i 

A/N 

Required 

3 

Plight 

8-12 

5 

A/N 

Optional 

m 

Number 

• 

• 

• 

; • 

• 

m 

• 

16 

• 

• 

Plight 

• 

• 

73-77 

• 

• 

5 

e 

9> 

A/N 

• 

• 

Optional 


A- 14 


TITLE 


EDIT TABLE UPDATE CARD FORHAT 


TYPE: Edit Table Card 


Item 

yiumber 

Name 

Card 

Columns 

Size 

Iipe 

Comments 

1 

Identifier 

1-2 

2 

H 

Required - 

2 

Table Code 

3-4 

2 

N 

must be 27 
Required - 

3 

Update 

5 

1 

A 

may be 01, 
02, 03, 04 
05, 06, 07 
or 08, 
Required - 

4 

Function 
Hew data 

6-21 

15 

A/N 

must be A 
or D. 

Required - 


D£kta to be 
deleted or 
added must 
be coded 
beginning in 
column 6. 
Depending on 
Table code 
contained in 
columns 3-4, 
this field 
will vary. 


A-15 



TITI.S: 

NASS PROPEBTIES 

TAPE CABO 

FORHAT 



TYPE: 

Na 9 s Properties Card 




Item 


Card 

' 



Eill^ 

Name 

Columns 


IlfiS 

Comments 

1 

Identifier 

1-2 

1 

\ i 

N 

Beguired - 
must be 28 

2 

Flight 

3-7 

5 

A/N 

Required. 


TITLE; 

HISTORY PROCESSING AND REPORT PROGRAM 


TYPE: 

History Processing 

Card 




Item 


Card 




EttBl2S£ 

Name 

Columns 

Size 


Comments 

1 

Report Number 

1-2 

2 

N 

Required - 






must be 29. 

2 

Selection 

3 


K 

Required - 


Option 




must be 0 






or 1 . 


A- 16 



TITLES QA DATA BASE LOAD PROGHAM CARD FORMAT 


TYPE: 

Data Base Load 

Card 




Item 

Humber 

1 

Name 

Identifier 

< 

Card 

Columns 

1-2 

1 

Size 

2 

N 

Comments 
Required - 
must be 30 



APPENDIX B 

REPEATING GROUP SPECIFICATIONS 
FOR THE 

SLAHTS DATA BASE 



E ntry Des cri pt or s 

The component description for an element within a 
repeating group in the SLAHTS data base will contain five 
coBBion ingredients. They are: 

1. Component Number - This number is completely 
transparent to the user and, due to increased 
efficiency, will be used within the SLAHTS to 
reference data- 

2. Name - The data element associated with the above 
mentioned Component Number. 

3. Size - The maximum number of allowable characters 
which can be specified for any data name. 

4. Type - The data element type is crucial for storing 
values within the data base. There are five 
allowable specifications, each of which is 
discussed below: 

(a) NAME - Any alphanumeric data with all leading, 
trailing, and extraneous (more than one) 
embedded blanks discarded when the data is 
siofed. A single embedded blank is retained 
between syntactic units, e.g., an input value 
of JOHN SMITH is stored as JOHN SMITH- 

(b) TEXT - Any alphanumeric data with all blanks 
being retained in the data. Text is the 
element type selected when storing reports or 



graphics where control of blank storage is 
inperative to maintain the original appearance 
of the material. 

(c) DATE * A fixed format statement of HHDDYY 

standing for month, dayc and year. For 
calculations involving DATE type values, each 
date in the data base is considered to be the 
number of days elapsed since 10/15/1582 (day 
zero) . ' 

(d) INTEGER NUMBER A. string of numerals (0-9), 
plus the sign, restricted by the size 
designation. 

5. KEY, NON-KEY - All elements which are specified as 
KEY may be used within the SLAHTS for WHERE clause 
gualif ication . This of course, provides great 
flexibility in retrieval and updating activities 
within the data base. 


In the Data Set descriptions which follow, all elements 
nr« NON^KEY unless otherwise specified in the COnHENTS 
. column. 



5S 

CM 



FIGURE B-l SLAHTS DATA BASE MAP 














TITLE: 

BASIC DATA SET 

TtPE: 

Repeating Group 

LEVEL: 

0 


Colponent 


■Jiiafetl-,. 





1 

Itea Number 


12 

2 

Part Nuaber 


20 

3 

Training Part 





Number 


20 

4 

Responsible 





Organization 


4 

5 

Engineering 





Noaenclature 

1 

20 

6 

Engineering 





Noaenclature 

2 

20 

7 

Procedural 





Noaenclature 

1A 

20 

8 

Procedural 





: Noaenclature 

IB 

20 

9 

Procedural 





Noaenclature 

2A 

20 

10 

f Procedural 

I ; 





Noaenclature 

2B 

20 

11 

Current Weight 


7 

12 

Specification 





Weight 


6 

13 

Length 


5 


B-4 


5 

7 

9 


12 

H2& £sa£efits 1 3 

Nai€ All three ele- 14 

Naie aents are K EY 15 

and at least 16; 

Naae one aast be 17; 

1 

specified. 18 

19 

Nase 20 

21 

Naae 22 

23 

Naae 24 

25 

Naae 26 

■ , 27 

Nape 28 

29 

NaPe 30 

. 31 

Naae 32 

Naae 331 

34 

Naae 35 

Naae 36 



14 

Width 

6 

Name 

37 

15 

Height 

5 

Name 

38 

16 

Program Cdde. 

2 

Name 

39 

17 

Building 36 



40 


Reguirement 

3 

Number 

41 

18 

Current Building 



42 


36 Requirement 

4 

Number 

43 

19 

Current Other 



44 


Inventory 

4 

Number 

45 

20 

Building 36 



46 


Accountability 

4 

Number 

47 

21 

Replacement Lead 



48 


Time 

2 

Number 

49 

22 

Refurbishment Time 

2 

Number 

50 

23 

shelf Life 

2 

Number 

51 

24 

Operating Life 

4 

Name 

52 

25 

Cycle Life 

5 

Number 

53 

26 

Fit Check Require- 



54 


ment Flag 

1 

Name 

55 

27 

Unit of Issue 

4 

Number 

56 





57 


tITLE: EOTE BEFBBENCE DATA SET 59 
TYPE: B«peating Group 61 
IEVELs 1 63 
COHPOIEET: 28 65 


Couponent 

■uuber Haie 

29 Boforence Note 

Nuaber 


68 

Siz§ iTPe COB Mnta 69 

70 

4 Naae 71 


B-6 



TITLE: 

FUNCTION CODES DATA SET 

74 

TYPE: 

Repeating Group 

76 

LEVEL: 

1 

78 

COMPONENT: 

30 . 

80 


Conponent 




83 

jlug^er 


Size 

i Type Connents 

84 

31 

Function Systen 



8S 


Classification 


Name KEY 

86 

32 

Function Code 



87 


Identification 

1 

Name 

88 

33 

HinlDUB Req for 



89 


Function Code 



90 


Identification 

3 

Nunber 

91 





92 


B-7 


SBBIJkl. DATA SET 


94 


TITLE: 


TIPE: 

Serial Repeating 

Group 



96 

LEVEL: 

1 




98 

COHPONENT: 

34 

f 




100 

Coaponent 





102 


£US 


Type 

Coaaepts 

103 

35 

Serial Nueber 

14 

Naae 

KEY - nust be 

104 





specified. 

105 

36 

Claes Code ^ 

2 

Naae 

KEY 

106 

3l 

Authority Docunent 

12 

Naae 


107 

36 

Hork Order Nuaber 

6 

Naae 


108 

39 

Contract Nuaber 

8 

Naae 


109 

40 

Issue Date 

8 

Date 

MH/DD/TY 

110 

41 

Unit Serial 


' , 


111 


Nuaber Neight 

6 

Naae 


112 

42 

Pit Check Coaplete 

' 



113 


Flag 

1 

Naae 


114 

43 

Operating Life 




115 


Beaaining 

4 

Naae 


116 

44 

Cycle Life 




117 


Beaaining 

5 

Naae 


118 

45 

Shelf Life 




119 


Expiration Date 

$ 

Date 

HM/DD/YY 

1 2b 

46 

Expected Delivery 




121 


Date to Bldg 36 

8 

Date 

HH/DD/YY 

122 

47 

Serial Fidelity 




123 


Code 

14 

Naae 


124 






125 


B-8 


TITLE: 

B0ILDIN6 LOCATION DATA SET 

t 


127 

TYPE: 

Be pea ting Sroup 


129 

LEVEL: 

2 


131 

COHPONENT: 

48 


133 


Conponent 




136 

Nueber 

Name 

Size 

Type 

Comments 137 

49 

Hacdifare Transfer 



138 


Date 

8 

Date 

139 

50 

Building location 

11 

Nane 

140 

51 

Building Quantity 

2 

Number 

141 





142 


TITLE: 

CABINET LOCATION DATA SET 

144 

TYPE: 

Repeating Group 

146 

LEVEL: 

3 

148 

COBPONENTr 

52 

150 


Component 

Name 

Size 

Type 

Comments 

153 

154 

53 

Cabinet Quantity 

2 

Number 


155 

54 

Cabinet I.D. 

6 

Name 


156 


1^37 


B-9 



TITLE: 

SOSPENSE DATA SET 

159 

TYPE; 

Repeating Group 

161 

LEVEL: 

2 

K 

163 

COHPOVENT: 

55 

165 


Coiponent 

1 

' 




168 

_IiiBber 

Hane 


Type 

Sfiussifi 

169 

56 

Shipping Building 

12 

|Baee 



170 

57 

Cabinet 1 

6 

^ane 



171 

58 

Cabinet Qty>. 

2 

Hunber 

1 ■ 



172 

59 

Cabinet 2 

6 

Nane 



173 

60 

1 Cabinet Qty 

2 

Kunber 



174 

61 

Cabinet 3 

6 

Nane 



175 

62 

Cabinet Qty 

2 

Hunber 



176 


Receiving Building 

12 

Nane 

KEY 


177 

64 

Shipping Authority 





178 


Doc 

12 

Nane 



179 

65 

Due Date 

8 

Date 



180 







181 


B-10 



i 


TITLE: 

HISTORY DATA SET 

183 

TYPE: 

Bepeating Group 

135 

LEVEL: 

2 

187 

COflPONENT: 

66 

189 


Conponent 





192 

NuBber 

Name 


Type 

Comments 

193 

67 

Old Building 


194 


Location 

12 

Name 


195 

68 

Authority Document 

12 

Name 


196 

69 

Transfer Date 

6 

Date 


197 

70 

Historical Progress 




198 


Code 

2 

Name 


199 


200 


TITLE: 

FLIGHT ITEM NOHBEB 

DATA 

SET 

TYPE: 

Repeating Group 



LEVEL: 

2 



CpflPOBEHT: 

74 



Component 





N^ae 

Size 

XIC§ 

75 

Reference Item 




Humber 

12 

Name 

76 

Reference Engineer- 




ing Noiiiiencla- 




ture 1 

20 

Name 

77 

Reference Engineer- 




ing Nomencla- 




ture 2 

20 

Name 

78 

Reference Procedu- 




ral Nomencla- 




ture 2A 

20 

Name 

79 

Reference Procedu- 




ral Nomencla- 




ture 2B 

20 

Name 

80 

Total Operational 



■ 

Quantity 

2 

Number 

81 

Total Payload 




Quantity 

2 

Number 

82 

Landing Site 




Disposition 

4 

Name 

83 

Post Flight 




Disposition 

15 

Name 


SgllSflli 

m 


B-12 



V 


TITLE; 

PLIGHT LOCATION DATA SET 

TYPE: 

Repeating Group 

LEVEL: 

3 

COMPONENT: 

84 


Component 

Number 

Name 

Size 

Type Comments 

85 

plight Phase 

1 

Name 

86 

Phase Location 

6 

Name KEY 

87 

Phase Location 




Quantity 

2 

Number 


TITLE: 

SERIAL REFERENCE 

DATA SET 



TYPE: 

Repeating Group 




LEVEL: 

4 




COMPONENT: 

88 




Component 

Number 

89 

Name 

Serial Reference 
Number 

Size 

14 

Type 

Name 

Comments 







B-13 


TITLE: 


TYPE: 


LEVEX.: 


STOWAGE LIST CHANGE NOT! 


Repeating Group 
3 


CORPONENT: 90 


Coiponent 

-IttllXSI N^e ^je 

91 S^L.C.N.Date 8 

92 S.L.C.N. Nunbec 4 

93 S.L.C.N. 

Description 120 


TITLE: NOTES DATA SET 

TYPE: Repeating Group 


LEVEL: 

1 

CORPONENT: 

94 


Coiponent 






Name 

Si^e 

95 

Note 

Nunber 

4 

96 

Note 

Text 

120 


B-14 


DATA SET 


k 

Szpe £oii£]|i^s 

Date K^l 


NuBber 

Text 



i 

t 


! 

I 

Name KEY 
Text 









